Configuring IP Profiles

The IP Profiles table lets you configure up to 1,500 or 5,000 if License Key includes the VoiceAI Connect feature (SE), 150 (VE/CE 2 GB), 300 (VE/CE 5-32 GB), and 1,500 or 5,000 if License Key includes the VoiceAI Connect feature (VE/CE 64 GB) IP Profiles. An IP Profile is a set of parameters with user-defined settings relating to signaling (e.g., SIP message terminations such as REFER) and media (e.g., coder type). An IP Profile can later be assigned to specific IP calls (inbound and/or outbound). Thus, IP Profiles provide high-level adaptation when the device interworks between different SIP user agents (UA), each of which may require different handling by the device. This can include, for example, transcoding or even transrating (of packetization time). For example, if a specific SIP UA uses the G.711 coder only, you can configure an IP Profile with G.711 for this UA.

Many parameters in the IP Profiles table have a corresponding "global" parameter, whose settings apply to all calls that are not associated with an IP Profile. The default value of these IP Profile parameters is the same as the default value of their corresponding global parameters. However, if you change a global parameter from its default value, the value of its corresponding IP Profile parameter inherits its value for all subsequently created (new) IP Profiles. For example, the IP Profile parameter for configuring maximum call duration is 'Max Call Duration'. Its corresponding global parameter is [SBCMaxCallDuration]. The default of the global parameter is "0" and therefore, the default of this IP Profile parameter is also "0". However, if you configure the global parameter to "10", the value of this IP Profile parameter for all subsequently created (new) IP Profiles is also "10".

To use your IP Profile for specific calls, you need to assign it to any of the following:

■ IP Groups - see Configuring IP Groups

You can also use IP Profiles when using a Proxy server (when the AlwaysUseRouteTable parameter is set to 1).

The following procedure describes how to configure IP Profiles through the Web interface. You can also configure it through ini file [IPProfile] or CLI (configure voip > coders-and-profiles ip-profile).

➢ To configure an IP Profile:
1. Open the IP Profiles table (Setup menu > Signaling & Media tab > Coders & Profiles folder > IP Profiles).
2. Click New; the following dialog box appears:

3. Configure an IP Profile according to the parameters described in the table below.
4. Click Apply.

IP Profiles Table Parameter Descriptions

Parameter

Description

General

'Index'

[Index]

Defines an index number for the new table row.

Note: Each row must be configured with a unique index.

'Name'

profile-name

[ProfileName]

Defines a descriptive name, which is used when associating the row in other tables.

The valid value is a string of up to 40 characters.

Note:

■ Configure each row with a unique name.
■ The parameter value can't contain a forward slash (/).
■ The parameter value can't be configured with the character string "any" (upper or lower case).

'Created By Routing Server'

created-by-routing-server

[CreatedByRoutingServer]

(Read-only) Indicates whether the IP Profile was created by a third-party routing server or ARM:

■ [0] No
■ [1] Yes

For more information on the third-party routing server or ARM feature, see Centralized Third-Party Routing Server.

'Used By Routing Server'

used-by-routing-server

[UsedByRoutingServer]

Enables the IP Profile to be used by a third-party routing server or ARM for call routing decisions.

■ [0] Not Used (default)
■ [1] Used

For more information on the third-party routing server or ARM feature, see Centralized Third-Party Routing Server.

Media Security

'SBC Media Security Mode'

sbc-media-security-behaviour

[SBCMediaSecurityBehaviour]

Defines the handling of RTP/SRTP, and MSRP/MSRPS for the SIP UA associated with the IP Profile.

■ [0] As is = (Default) No special handling for RTP/SRTP and MSRP/MSRPS is done.
■ [1] Secured = SBC legs negotiate only SRTP/MSRPS media lines, and RTP/MSRP media lines are removed from the incoming SDP offer-answer.
■ [2] Not Secured = SBC legs negotiate only RTP/MSRP media lines, and SRTP/MSRPS media lines are removed from the incoming offer-answer.
■ [3] Both = Each offer-answer is extended (if not already) to two media lines - one RTP/MSRP and the other SRTP/MSRPS.
■ [4] Offer Both - Answer Prefer Secured = The device prefers secured media on the outgoing SDP answer. If the incoming SDP offer contains secured media, the device sends the outgoing SDP answer with secured media, regardless of the incoming SDP answer (media secured or not). The device's handling for secured media on the SDP offer side is the same as the Both option.

If two SBC legs (after offer-answer negotiation) use different security types (i.e., one RTP/MSRP and the other SRTP/MSRPS), the device performs RTP-SRTP/MSRP-MSRPS transcoding. For such transcoding, the following prerequisites must be met:

■ At least one supported SDP "crypto" attribute and parameters.
■ The [EnableMediaSecurity] parameter must be configured to [1]. (This prerequisite is not applicable to WebRTC calls.)

If one of the above prerequisites is not met, then:

■ any value other than As is is discarded.
■ if the incoming offer is SRTP/MSRPS, forced transcoding, coder transcoding, and DTMF extensions are not applied.

Note: For secured MSRP (MSRPS), configure the parameter to Secured or Both. For more information on MSRP, see Configuring Message Session Relay Protocol.

'Symmetric MKI'

enable-symmetric-mki

[EnableSymmetricMKI]

Enables symmetric MKI negotiation.

■ [0] Disable = (Default) The device includes the MKI in its SIP 200 OK response according to the [SRTPTxPacketMKISize] parameter (if set to 0, it is not included; if set to any other value, it is included with this value).
■ [1] Enable = The answer crypto line contains (or excludes) an MKI value according to the selected crypto line in the offer. For example, assume that the device receives an INVITE containing the following two crypto lines in SDP:

a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:TAaxNnQt8/qLQMnDuG4vxYfWl6K7eBK/ufk04pR4|2^31|1:1

a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:bnuYZnMxSfUiGitviWJZmzr7OF3AiRO0l5Vnh0kH|2^31

The first crypto line includes the MKI parameter "1:1". In the 200 OK response, the device selects one of the crypto lines (i.e., '2' or '3'). Typically, it selects the first line that supports the crypto suite. However, for SRTP-to-SRTP in SBC sessions, it can be determined by the remote side on the outgoing leg. If the device selects crypto line '2', it includes the MKI parameter in its answer SDP, for example:

a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:R1VyA1xV/qwBjkEklu4kSJyl3wCtYeZLq1/QFuxw|2^31|1:1

If the device selects a crypto line that doesn't contain the MKI parameter, then the MKI parameter is not included in the crypto line in the SDP answer (even if the [SRTPTxPacketMKISize] parameter is set to any value other than 0).

Note: The corresponding global parameter is [EnableSymmetricMKI].

'MKI Size'

mki-size

[MKISize]

Defines the size (in bytes) of the Master Key Identifier (MKI) in SRTP Tx packets.

The valid value is 0 to 4. The default is 0 (i.e., new keys are generated without MKI).

Note:

■ The device can forward MKI size as is for SRTP-to-SRTP flows or override the MKI size during negotiation. This can be done on the inbound or outbound leg.
■ The corresponding global parameter is SRTPTxPacketMKISize.

'SBC Enforce MKI Size'

sbc-enforce-mki-size

[SBCEnforceMKISize]

Enables negotiation of the Master Key Identifier (MKI) length for SRTP-to-SRTP flows between SIP networks (i.e., IP Groups). This includes the capability of modifying the MKI length on the inbound or outbound SBC call leg for the SIP UA associated with the IP Profile.

■ [0] Don't enforce = (Default) Device forwards the MKI size as is.
■ [1] Enforce = Device changes the MKI length according to the settings of the IP Profile parameter, MKISize.

'SBC Media Security Method'

sbc-media-security-method

[SBCMediaSecurityMethod]

Defines the media security protocol for SRTP, for the SIP UA associated with the IP Profile.

■ [0] SDES = (Default) The device secures RTP using the Session Description Protocol Security Descriptions (SDES) protocol to negotiate the cryptographic keys (RFC 4568). The keys are sent in the SDP body ('a=crypto') of the SIP message and are typically secured using SIP over TLS (SIPS). The encryption of the keys is in plain text in the SDP. SDES implements TLS over TCP.
■ [1] DTLS = The device uses Datagram Transport Layer Security (DTLS) protocol to secure UDP-based media streams (RFCs 5763 and 5764). For more information on DTLS, see SRTP using DTLS Protocol.
■ [2] Both = SDES and DTLS protocols are supported.

Note:

■ To support DTLS, you must also configure the following for the SIP UA:
✔ TLS Context for DTLS (see Configuring TLS Certificate Contexts). The server cipher ('Cipher Server') must be configured to All.
✔ 'SBC Media Security Mode' parameter to Secured or Both.
✔ 'RTCP Mux' parameter to Supported. The setting is required as the DTLS handshake is done for the port used for RTP. Therefore, RTCP and RTP should be multiplexed over the same port.
■ The device doesn't support forwarding of DTLS transparently between SIP UAs.
■ As DTLS has been defined by the WebRTC standard as mandatory for encrypting media channels for SRTP key exchange, the support is important for deployments implementing WebRTC. For more information on WebRTC, see WebRTC.

'Reset SRTP Upon Re-key'

reset-srtp-upon-re-key

[ResetSRTPStateUponRekey]

Enables synchronization of the SRTP state between the device and a server when a new SRTP key is generated upon a SIP session expire. This feature ensures that the roll-over counter (ROC), one of the parameters used in the SRTP encryption/decryption process of the SRTP packets is synchronized on both sides for transmit and receive packets.

■ [0] Disable = (Default) ROC is not reset on the device side.
■ [1] Enable = If the session expires causing a session refresh through a re-INVITE, the device or server generates a new key and the device resets the ROC index (and other SRTP fields) as done by the server, resulting in a synchronized SRTP.

Note:

■ If this feature is disabled and the server resets the ROC upon a re-key generation, one-way voice may occur.
■ The corresponding global parameter is [ResetSRTPStateUponRekey].

'Generate SRTP Keys Mode'

generate-srtp-keys

[GenerateSRTPKeys]

Enables the device to generate a new SRTP key upon receipt of a re-INVITE with the SIP UA associated with the IP Profile.

■ [0] Only If Required = (Default) The device generates an SRTP key only if necessary.
■ [1] Always = The device always generates a new SRTP key.

'SBC Remove Crypto Lifetime in SDP'

sbc-sdp-remove-crypto-lifetime

[SBCRemoveCryptoLifetimeInSDP]

Defines the handling of the lifetime field in the 'a=crypto' attribute of the SDP for the SIP UA associated with the IP Profile. The SDP field defines the lifetime of the master key as measured in maximum number of SRTP or SRTCP packets using the master key.

■ [0] No = (Default) The device retains the lifetime field (if present) in the SDP.
■ [1] Yes = The device removes the lifetime field from the 'a=crypto' attribute.

Note:

■ If you configure the parameter to Yes, the following IP Profile parameters must be configured as follows:
✔ 'Symmetric MKI' to Enable.
✔ 'MKI Size' to 0.
✔ 'SBC Enforce MKI Size' to Enforce.

'SBC Remove Unknown Crypto'

sbc-remove-unknown-crypto

[SBCRemoveUnKnownCrypto]

Defines whether the device keeps or removes unknown cryptographic suites (encryption and authentication algorithms) that are present in the SDP 'a=crypto' attribute in the incoming SIP message, before forwarding the message to the SIP UA associated with this IP Profile.

■ [0] No = (Default) The device keeps all unknown cryptographic suites that are in the SDP’s 'a=crypto' attribute.
■ [1] Yes = The device removes all unknown cryptographic suites that are in the SDP’s 'a=crypto' attribute.

Note:

■ The feature is applicable only to SRTP-to-SRTP calls and calls that do not require transcoding.

'Crypto Suites Group'

crypto-suites-group

[SBCCryptoGroupName]

 

Assigns an SBC Crypto Suite Group to the IP Profile, which defines the supported SRTP crypto suites.

By default, the parameter is undefined and the crypto suite used by the IP Profile is according to the global parameter [SRTPofferedSuites].

For configuring SBC Crypto Suite Groups, see Configuring SRTP Crypto Suite Groups.

'Encryption on RTCP Packets'

rtcp-encryption

[RTCPEncryption]

Defines the encryption of RTCP packets (i.e., SRTCP).

■ [0] Active =
✔ Incoming leg (SRTP-SRTP / SRTP-RTP calls): SRTP cryptos in the incoming SDP offer with the UNENCRYPTED_SRTCP flag are rejected.
✔ Outgoing leg (SRTP-SRTP / RTP-SRTP calls): The device removes the UNENCRYPTED_SRTCP from all cryptos in the outgoing SDP offer.
■ [1] InActive =
✔ Incoming leg (SRTP-SRTP / SRTP-RTP calls): SRTP cryptos in the incoming SDP offer without the UNENCRYPTED_SRTCP flag are rejected.
✔ Outgoing leg (SRTP-SRTP / RTP-SRTP calls): The device adds the UNENCRYPTED_SRTCP to all cryptos in the outgoing SDP offer.
■ [2] As Is = (Default)
✔ Incoming leg (SRTP-SRTP / SRTP-RTP calls): The device does nothing.
✔ Outgoing leg: Cryptos that are received in the incoming leg are not modified. For new cryptos generated by device the encryption flag is set according to the global parameter [RTCPEncryptionDisableTx].

SBC Early Media

'Remote Early Media'

sbc-rmt-early-media-supp

[SBCRemoteEarlyMediaSupport]

Defines whether the remote side can accept early media or not.

■ [0] Not Supported = Early media is not supported.
■ [1] Supported = (Default) Early media is supported.

'Remote Multiple 18x'

sbc-rmt-mltple-18x-supp

[SBCRemoteMultiple18xSupport]

Defines whether multiple 18x responses including 180 Ringing, 181 Call is Being Forwarded, 182 Call Queued, and 183 Session Progress are forwarded to the caller, for the SIP UA associated with the IP Profile.

■ [0] Not Supported = Only the first 18x response is forwarded to the caller.
■ [1] Supported = (Default) Multiple 18x responses are forwarded to the caller.

'Remote Early Media Response Type'

sbc-rmt-early-media-resp

[SBCRemoteEarlyMediaResponseType]

Defines the SIP provisional response type - 180 or 183 - for forwarding early media to the caller, for the SIP UA associated with the IP Profile.

■ [0] Transparent = (Default) All early media response types are supported; the device forwards all responses as is (unchanged).
■ [1] 180 = Early media is sent as 180 response only.
■ [2] 183 = Early media is sent as 183 response only.

'Remote Multiple Early Dialogs'

sbc-multi-early-diag

[SBCRemoteMultipleEarlyDialogs]

Defines the device's handling of To-header tags in call forking responses (i.e., multiple SDP answers) sent to the SIP UA associated with the IP Profile.

When the SIP UA initiates an INVITE that is subsequently forked (for example, by a proxy server) to multiple UAs, the endpoints respond with a SIP 183 containing an SDP answer. Typically, each endpoint's response has a different To-header tag. For example, a call initiated by the SIP UA (100@A) is forked and two endpoints respond with ringing, each with a different tag:

■ Endpoint "tag 2":

SIP/2.0 180 Ringing
From: <sip:100@A>;tag=tag1
To: sip:200@B;tag=tag2
Call-ID: c2

■ Endpoint "tag 3":

SIP/2.0 180 Ringing
From: <sip:100@A>;tag=tag1
To: sip:200@B;tag=tag3
Call-ID: c2

In non-standard behavior (when the parameter is configured to Disable), the device forwards all the SDP answers with the same tag. In the example, endpoint "tag 3" is sent with the same tag as endpoint "tag 2" (i.e., To: sip:200@B;tag=tag2).

■ [-1] According to Operation Mode = (Default) Depends on the setting of the 'Operation Mode' parameter in the IP Group or SRDs table:
✔ B2BUA: Device operates as if the parameter is set to Disable [0].
✔ Call State-full Proxy: Device operates as if the parameter is set to Enable [1]. In addition, the device preserves the From tags and Call-IDs of the endpoints in the SDP answer sent to the SIP UA.
■ [0] Disable = Device sends the multiple SDP answers with the same To-header tag, to the SIP UA. In other words, this option is relevant if the SIP UA doesn't support multiple dialogs (and multiple tags). However, non-standard, multiple answer support may still be configured by the SBCRemoteMultipleAnswersMode parameter.
■ [1] Enable = Device sends the multiple SDP answers with different To-header tags, to the SIP UA. In other words, the SIP UA supports standard multiple SDP answers (with different To-header tags). In this case, the SBCRemoteMultipleAnswersMode parameter is ignored.

Note: If the parameter and the SBCRemoteMultipleAnswersMode parameter are disabled, multiple SDP answers are not reflected to the SIP UA (i.e., the device sends the same SDP answer in multiple 18x and 200 responses).

'Remote Multiple Answers Mode'

sbc-multi-answers

[SBCRemoteMultipleAnswersMode]

Enables interworking multiple SDP answers within the same SIP dialog (non-standard). The parameter enables the device to forward multiple answers to the SIP UA associated with the IP Profile. The parameter is applicable only when the 'Remote Multiple Early Dialogs' parameter is disabled.

■ [0] Disable = (Default) Device always sends the same SDP answer, which is based on the first received answer that it sent to the SIP UA, for all forked responses (even if the 'Forking Handling Mode' parameter is Sequential), and thus, may result in transcoding.
■ [1] Enable = If the 'Forking Handling Mode' parameter is configured to Sequential, the device sends multiple SDP answers.

'Remote Early Media RTP Detection Mode'

sbc-rmt-early-media-rtp

[SBCRemoteEarlyMediaRTP]

Defines whether the destination UA sends RTP immediately after it sends a 18x response.

■ [0] By Signaling = (Default) Remote client sends RTP immediately after it sends 18x response with early media. The device forwards 18x and RTP as is.
■ [1] By Media = After sending 18x response, the remote client waits before sending RTP (e.g., Microsoft Skype for Business environment). For the device's handling of this remote UA support, see Interworking SIP Early Media.

'Remote RFC 3960 Support'

sbc-rmt-rfc3960-supp

[SBCRemoteSupportsRFC3960]

Defines whether the destination UA is capable of receiving 18x messages with delayed RTP.

■ [0] Not Supported = (Default) UA doesn't support receipt of 18x messages with delayed RTP. For the device's handling of this remote UA support, see Interworking SIP Early Media.
■ [1] Supported = UA is capable of receiving 18x messages with delayed RTP.

'Remote Can Play Ringback'

sbc-rmt-can-play-ringback

[SBCRemoteCanPlayRingback]

Defines whether the destination UA can play a local ringback tone.

■ [0] No = UA doesn't support local ringback tone. The device sends 18x with delayed SDP to the UA.
■ [1] Yes = (Default) UA supports local ringback tone. For the device's handling of this remote UA support, see Interworking SIP Early Media.

'Generate RTP'

sbc-generate-rtp

[SBCGenerateRTP]

Enables the device to generate "silence" RTP packets to the SIP UA until it detects audio RTP packets from the SIP UA. The parameter provides support for interworking with SIP entities that wait for the first incoming packets before sending RTP (e.g., early media used for ringback tone or IVR) during media negotiation.

■ [0] None = (Default) Silence packets are not generated.
■ [1] Until RTP Detected = The device generates silence RTP packets to the SIP UA upon receipt of a SIP response (183 with SDP) from the SIP UA. In other words, these packets serve as the first incoming packets for the SIP UA. The device stops sending silence packets when it receives RTP packets from the peer side (which it then forwards to the SIP UA).

Note: To generate silence packets, DSP resources are required (except for calls using the G.711 coder).

SBC Media

'Mediation Mode'

transcoding-mode

[TranscodingMode]

Defines the transcoding mode (media negotiation) for the SIP UA associated with the IP Profile.

■ [0] RTP Mediation = (Default) Transcoding is done only if required. If not required, many of the media settings (such as gain control) are not applied to the voice stream. The device forwards the RTP packets transparently (i.e., RTP-to-RTP) without processing the data; only the RTP headers are re-constructed.
■ [1] Force Transcoding = This enables the device to receive capabilities that are not negotiated between the SIP entities, by implementing DSP transcoding. For example, it can enforce gain control to use voice transcoding even though both legs have negotiated without the device's intervention (such as Extension coders).
■ [2] RTP Forwarding = If transcoding is not required and both legs are configured with RTP forwarding, then RTP packets are forwarded transparently without any processing. This mode is needed when the call parties pass invalid RTP packets on the RTP port. If you use this option, you may also need to configure the global parameters 'Forward Unknown RTP Payload Types' to Handle as Valid Packet, and 'Forward Invalid RTP Packets' to Forward Packets.

Note:

■ For transcoding, make sure that the device's License Key includes a license for the number of transcoding sessions ('Transcoding Sessions'). For more information on the License Key, see License Key.
■ To enable transcoding for Mediant VE, make sure that you configure the 'SBC Performance Profile' parameter to Optimized for Transcoding.
■ The corresponding global parameter is [TranscodingMode].

'Extension Coders Group'

sbc-ext-coders-group-name

[SBCExtensionCodersGroupName]

Assigns a Coder Group for extension coders, which are added to the SDP offer in the outgoing leg for the SIP UA associated with the IP Profile. This is used when transcoding is required between two IP entities (i.e., the SDP answer from one doesn’t include any coder included in the offer previously sent by the other).

For more information on extension coders and transcoding, see Coder Transcoding. To configure Coder Groups, see Configuring Coder Groups.

'Allowed Audio Coders'

allowed-audio-coders-group-name

[SBCAllowedAudioCodersGroupName]

Assigns an Allowed Audio Coders Group, which defines audio (voice) coders that can be used for the SIP UA associated with the IP Profile.

To configure Allowed Audio Coders Groups, see Configuring Allowed Audio Coder Groups. For a description of the Allowed Coders feature, see Restricting Coders.

'Allowed Coders Mode'

sbc-allowed-coders-mode

[SBCAllowedCodersMode]

Defines the mode of the Allowed Coders feature for the SIP UA associated with the IP Profile.

■ [0] Restriction = In the incoming SDP offer, the device uses only Allowed coders; the rest are removed from the SDP offer (i.e., only coders common between those in the received SDP offer and the Allowed coders are used). If an Extension Coders Group is also assigned (using the 'Extension Coders Group' parameter, above), these coders are added to the SDP offer if they also appear in Allowed coders.
■ [1] Preference = The device re-arranges the priority (order) of the coders in the incoming SDP offer according to their order of appearance in the Allowed Audio Coders Group or Allowed Video Coders Group. The coders in the original SDP offer are listed after the Allowed coders.
■ [2] Restriction and Preference = Performs both Restriction and Preference.

Note:

■ The parameter is applicable only if Allowed coders are assigned to the IP Profile (see the 'Allowed Audio Coders' or 'Allowed Video Coders' parameters).
■ For more information on the Allowed Coders feature, see Restricting Coders.

'Allowed Video Coders'

allowed-video-coders-group-name

[SBCAllowedVideoCodersGroupName]

Assigns an Allowed Video Coders Group. This defines permitted video coders when forwarding video streams to the SIP UA associated with the IP Profile. The video coders are listed in the "video" media type in the SDP (i.e., 'm=video' line). For this SIP UA, the device uses only video coders that appear in both the SDP offer and the Allowed Video Coders Group.

By default, no Allowed Video Coders Group is assigned (i.e., all video coders are allowed).

To configure Allowed Video Coders Groups, see Configuring Allowed Video Coder Groups.

'Allowed Media Types'

sbc-allowed-media-types

[SBCAllowedMediaTypes]

Defines media types permitted for the SIP UA associated with the IP Profile. The media type appears in the SDP 'm=' line (e.g., 'm=audio'). The device permits only media types that appear in both the SDP offer and this configured list. If no common media types exist between the SDP offer and this list, the device drops the call.

The valid value is a string of up to 64 characters. To configure multiple media types, separate the strings with a comma, e.g., " audio, text" (without quotation marks). By default, no media types are configured (i.e., all media types are permitted).

'Direct Media Tag'

sbc-dm-tag

[SBCDirectMediaTag]

Defines an identification tag for enabling direct media or media bypass (i.e., no Media Anchoring) of SBC calls for the SIP UA associated with the IP Profile. Direct media occurs between all UAs whose IP Profiles have the same tag value (non-empty value). For example, if you configure the parameter to "direct-rtp" for two IP Profiles "IP-PBX-1" and "IP-PBX-2", the device employs direct media for calls of UAs associated with IP Profile "IP-PBX-1", for calls of UAs associated with IP Profile "IP-PBX-2", and for calls between UAs associated with IP Profile "IP-PBX-1" and IP Profile "IP-PBX-2".

The valid value is a string of up to 16 characters. By default, no value is defined.

For more information on direct media, see Direct Media.

Note:

■ If you enable direct media for the IP Profile, make sure that your Media Realm provides enough ports, as media may traverse the device for mid-call services (e.g., call transfer).
■ If you have configured a SIP Recording rule (see SIPREC SIP-based Media Recording) for calls associated with this IP Profile, the device automatically disables direct media for these calls (during their SIP signaling setup). This ensures that the media passes through the device so that it can be recorded and sent to the SRS. However, if you enable direct media using the [SBCDirectMedia] global parameter (i.e., for all calls), direct media is always enforced and calls will not be recorded.
■ Regardless of this parameter's settings, the device always handles calls whose incoming SIP dialog-initiating request (e.g., INVITE message) contains the proprietary SIP header 'X-AC-Action' with the value 'direct-media' (i.e., 'X-AC-Action: direct-media'), as direct media calls. These calls remain as direct media calls until they end.

'RFC 2833 Mode'

sbc-rfc2833-behavior

[SBCRFC2833Behavior]

Defines the handling of RFC 2833 SDP offer-answer negotiation for the SIP UA associated with the IP Profile.

■ [0] As is = (Default) The device doesn't intervene in the RFC 2833 negotiation.
■ [1] Extend = Each outgoing offer-answer includes RFC 2833 in the offered SDP. The device adds RFC 2833 only if the incoming offer doesn't include RFC 2833.
■ [2] Disallow = The device removes RFC 2833 from the incoming offer.

Note: If the device interworks between different DTMF methods and one of the methods is in-band DTMF packets (in RTP), detection and generation of DTMF methods requires DSP resources. However, RFC 2833 to SIP INFO doesn't require DSP resources.

'RFC 2833 DTMF Payload Type'

sbc-2833dtmf-payload

[SBC2833DTMFPayloadType]

Defines the payload type of DTMF digits for the SIP UA associated with the IP Profile. The parameter enables the interworking of the DTMF payload type for RFC 2833 between different SBC call legs. For example, if two entities require different DTMF payload types, the SDP offer received by the device from one UA is forwarded to the destination UA with its payload type replaced with the configured payload type, and vice versa.

The value range is 0 to 200. The default is 0 (i.e., the device forwards the received payload type as is).

■ For non-terminated calls:
✔ Outgoing SDP offer: The payload type configured for the parameter is used. If not configured, the device uses the payload type of the incoming offer.
✔ Outgoing SDP answer: If the payload type is configured for one of the IP Profiles, the payload type of the SDP offer is used. Otherwise, the payload type of the incoming SDP answer is used.
■ For terminated calls:
✔ Outgoing SDP offer: The payload type configured for the parameter is used. If not configured and there is a peer leg, the payload of the SDP created by the peer leg is used. Otherwise, the device uses a default payload type.
✔ Outgoing SDP answer: If the payload type is configured for one of the IP Profiles, the payload type of the SDP offer is used. Otherwise, the payload type of the peer incoming stream is used.

'Alternative DTMF Method'

sbc-alternative-dtmf-method

[SBCAlternativeDTMFMethod]

The device's first priority for DTMF method at each leg is RFC 2833. Thus, if the device successfully negotiates RFC 2833 for the SIP UA associated with the IP Profile, the chosen DTMF method for this leg is RFC 2833. When RFC 2833 negotiation fails, the device uses the DTMF method configured by this parameter for the leg.

■ [0] As Is = (Default) The device doesn't attempt to interwork any special DTMF method.
■ [1] In Band
■ [2] INFO - Cisco
■ [3] INFO - Nortel
■ [4] INFO - Lucent = INFO, Korea
■ [5] HTTP

Note:

■ If the device interworks between different DTMF methods and one of the methods is in-band DTMF packets (in RTP), detection and generation of DTMF methods requires DSP resources. However, RFC 2833 to SIP INFO doesn't require DSP resources.
■ The HTTP option is for internal use and applicable only when the device is deployed with AudioCodes VoiceAI Connect solution.

'Send Multiple DTMF Methods'

sbc-send-multiple-dtmf-methods

[SBCSupportMultipleDTMFMethods]

Enables the device to send DTMF digits out-of-band (not with audio stream) using both the SIP INFO and RFC 2833 methods for the same call on the leg to which this IP Profile is associated. The RFC 2833 method sends out-of-band DTMF digits using the RTP protocol while the SIP INFO method sends the digits using the SIP protocol.

■ [0] Disable = (Default) The device sends DTMF digits using only one method (either SIP INFO, RFC 2833, or in-band).
■ [1] Enable = The device sends DTMF digits using both methods - SIP INFO and RFC 2833.

If you have enabled the parameter, you can also configure the device to stop sending DTMF digits using the SIP INFO method if the device receives a SIP re-INVITE (or UPDATE) from the SIP UA to where the SIP INFO is being sent (and keep sending the DTMF digits using the RFC 2833 method). This is done using the AudioCodes proprietary SIP header X-AC-Action and a Message Manipulation rule (inbound) to instruct the device to switch to a different IP Profile that is configured to disable the sending of DTMF digits using both methods (i.e., 'Send Multiple DTMF Methods' is configured to Disable):

X-AC-Action: 'switch-profile;profile-name=<IP Profile Name>'

If the IP Profile name contains one or more spaces, you must enclose the name in double quotation marks, for example:

X-AC-Action: 'switch-profile;profile-name="My IP Profile"'

The Message Manipulation rule adds the proprietary header with the value of the new IP Profile to the incoming re-INVITE or UPDATE message and as a result, the device uses the new IP Profile for the SIP UA and stops sending it SIP INFO messages. You can also configure an additional Message Manipulation rule to re-start the sending of the SIP INFO. For example, you can configure two Message Manipulation rules where the sending of both SIP INFO and RFC 2833 depends on the negotiated media port -- the device stops sending SIP INFO if the SDP of the re-INVITE or UPDATE message contains port 7550 and re-starts sending if the port is 8660. The rule that re-starts the SIP INFO switches the IP Profile back to the initial IP Profile that enables the sending of DTMF digits using both methods (i.e., 'Send Multiple DTMF Methods' is configured to Enable). The configured Message Manipulation rules for this example are shown below:

■ Index 1
✔ Message Type: reinvite.request
✔ Condition: body.sdp regex (.*)(m=audio 7550 RTP/AVP)(.*)
✔ Action Subject: header.X-AC-Action
✔ Action Type: Add
✔ Action Value: 'switch-profile;profile-name=ITSP-Profile-2'
■ Index 2
✔ Message Type: reinvite.request
✔ Condition: body.sdp regex (.*)(m=audio 8660 RTP/AVP)(.*)
✔ Action Subject: header.X-AC-Action
✔ Action Type: Add
✔ Action Value: 'switch-profile;profile-name=ITSP-Profile-1'

The Message Manipulation rules must be assigned to the SIP UA's IP Group, using the 'Inbound Message Manipulation Set' parameter.

Note:

■ To send DTMF digits using both methods (i.e., when the parameter is enabled), you need to also configure the following:
✔ Configure the 'Alternative DTMF Method' parameter to one of the SIP INFO options (INFO – Cisco, INFO – Nortel, or INFO – Lucent).
✔ Enable the sending of DTMF digits using the RFC 2833 method, by configuring the 'RFC 2833 Mode' parameter to As Is or Extend.
■ When using the X-AC-Action header to switch IP Profiles, it is recommended that the settings of the switched IP Profile are identical (except for the 'Send Multiple DTMF Methods' parameter) to the initial IP Profile in order to avoid any possible call handling errors.

'Receive Multiple DTMF Methods'

sbc-receive-multiple-dtmf-methods

[ReceiveMultipleDTMFMethods]

Enables the device to receive DTMF digits out-of-band (not with audio stream) using both the SIP INFO and RFC 2833 methods, but forwards the DTMF only using RFC 2833.

■ [0] Disable = (Default) The device receives DTMF digits only by the RFC 2833 method, if negotiated. Otherwise, the device uses the DTMF method according to the IP Profile's 'Alternative DTMF Method' parameter (see above). In other words, it receives DTMF digits ussing only one method only.
■ [1] Enable = The device receives DTMF digits using the SIP INFO message method even if both sides successfully negotiated the RFC 2833 method. In other words, both SIP INFO and RFC 2833 are used to detect DTMF digits by the device. However, the device forwards the DTMF using RFC 2833 only.

'Adapt RFC2833 BW to Voice coder BW'

sbc-adapt-rfc2833-bw-voice-bw

[SBCAdaptRFC2833BWToVoiceCoderBW]

Defines the 'telephone-event' type (8000 or 16000) in the SDP that the device sends in the outgoing SIP 200 OK message for DTMF payload negotiation (sampling rate).

■ [0] Disable = (Default) The device always sends the 'telephone-event' as 8000 in the outgoing SIP 200 OK, even if the SDP of the incoming INVITE contains multiple telephone-event types (e.g., 8000 and 16000).
■ [1] Enable = The type of 'telephone-event' that the device sends in the outgoing SIP 200 OK message is according to the coder type (narrowband or wideband). If narrowband, it sends the 'telephone-event' as 8000; if wideband, it sends it as 16000.

An example when the parameter is configured to Enable is shown below, whereby the 'telephone-event' is "16000" in the outgoing message due to the wideband coder:

SDP in incoming INVITE:

a=rtpmap:97 AMR-WB/16000/1 a=fmtp:97 mode-change-capability=2 a=rtpmap:98 AMR-WB/16000/1 a=fmtp:98 octet-align=1; mode-change-capability=2 a=rtpmap:100 AMR/8000/1 a=fmtp:100 mode-change-capability=2 a=rtpmap:99 telephone-event/16000/1 a=fmtp:99 0-15 a=rtpmap:102 telephone-event/8000/1 a=fmtp:102 0-15

SDP in outgoing 200 OK:

m=audio 6370 RTP/AVP 97 99
a=rtpmap:99 telephone-event/16000/1
a=fmtp:99 0-15
a=sendrecv
a=ptime:20
a=maxptime:120
a=rtpmap:97 AMR-WB/16000
a=fmtp:97 mode-change-capability=2;mode-set=0,1,2,3,4,5,6,7,

'SDP Ptime Answer'

sbc-sdp-ptime-ans

[SBCSDPPtimeAnswer]

Defines the packetization time (ptime) of the coder in RTP packets for the SIP UA associated with the IP Profile. This is useful when implementing transrating.

■ [0] Remote Answer = (Default) Use ptime according to SDP answer.
■ [1] Original Offer = Use ptime according to SDP offer.
■ [2] Preferred Value = Use the ptime according to the 'Preferred Ptime' parameter (see below) if it is configured to a non-zero value.

Note:

■ Regardless of the settings of this parameter, if a non-zero value is configured for the 'Preferred Ptime' parameter (see below), it is used as the ptime in the SDP offer.

'Preferred Ptime'

sbc-preferred-ptime

[SBCPreferredPTime]

Defines the packetization time (ptime) in msec for the SIP UA associated with the IP Profile, in the outgoing SDP offer.

If the 'SDP Ptime Answer' parameter (see above) is configured to Preferred Value [2] and the 'Preferred Ptime' parameter is configured to a non-zero value, the configured ptime is used (enabling ptime transrating if the other side uses a different ptime).

If the 'SDP Ptime Answer' parameter is configured to Remote Answer [0] or Original Offer [1] and the 'Preferred Ptime' parameter is configured to a non-zero value, the configured value is used as the ptime in the SDP offer.

The valid range is 0 to 200. The default is 0 (i.e., a preferred ptime is not used).

'Use Silence Suppression'

sbc-use-silence-supp

[SBCUseSilenceSupp]

Defines silence suppression support for the SIP UA associated with the IP Profile

■ [0] Transparent = (Default) Forward as is.
■ [1] Add = Enable silence suppression for each relevant coder listed in the SDP.
■ [2] Remove = Disable silence suppression for each relevant coder listed in the SDP.

Note:

■ This feature requires DSP resources.

'RTP Redundancy Mode'

sbc-rtp-red-behav

[SBCRTPRedundancyBehavior]

Enables interworking RTP redundancy negotiation support between SIP entities in the SDP offer-answer exchange (according to RFC 2198). The parameter defines the device's handling of RTP redundancy for the SIP UA associated with the IP Profile. According to the RTP redundancy SDP offer/answer negotiation, the device uses or discards the RTP redundancy packets. The parameter enables asymmetric RTP redundancy, whereby the device can transmit and receive RTP redundancy packets to and from a specific SIP UA, while transmitting and receiving regular RTP packets (no redundancy) for the other SIP UA involved in the voice path.

The device can identify the RTP redundancy payload type in the SDP for indicating that the RTP packet stream includes redundant packets. RTP redundancy is indicated in SDP using the "red" coder type, for example:

a=rtpmap:<payload type> red/8000/1

RTP redundancy is useful when there is packet loss; the missing information may be reconstructed at the receiver side from the redundant packets.

■ [0] As Is = (Default) The device doesn't interfere in the RTP redundancy negotiation and forwards the SDP offer/answer (incoming and outgoing calls) as is without interfering in the RTP redundancy negotiation.
■ [1] Enable = The device always adds RTP redundancy capabilities in the outgoing SDP offer sent to the SIP UA. Whether RTP redundancy is implemented depends on the subsequent incoming SDP answer from the SIP UA. The device doesn't modify the incoming SDP offer received from the SIP UA, but if RTP redundancy is offered, it will support it in the outgoing SDP answer. Select the option if the SIP UA requires RTP redundancy.
■ [2] Disable = The device removes the RTP redundancy payload (if present) from the SDP offer/answer for calls received from or sent to the SIP UA. Select the option if the SIP UA doesn't support RTP redundancy.

Note:

■ To enable the device to generate RFC 2198 redundant packets, use the 'RTP Redundancy Depth' parameter.
■ To configure the payload type in the SDP offer for RTP redundancy, use the [RFC2198PayloadType] parameter.

'RTCP Mode'

sbc-rtcp-mode

[SBCRTCPMode]

Defines how the device handles RTCP packets during call sessions for the SIP UA associated with the IP Profile. This is useful for interworking RTCP between SIP entities. For example, this may be necessary when incoming RTCP is not compatible with the destination SIP UA's (this IP Profile) RTCP support. In such a scenario, the device can generate the RTCP and send it to the SIP UA.

■ [0] Transparent = (Default) RTCP is forwarded as is (unless transcoding is done, in which case, the device generates RTCP on both legs).
■ [1] Generate Always = Generates RTCP packets during active and inactive (e.g., during call hold) RTP periods (i.e., media is 'a=recvonly' or 'a=inactive' in the INVITE SDP).
■ [2] Generate only if RTP Active = Generates RTCP packets only during active RTP periods. In other words, the device doesn't generate RTCP when there is no RTP traffic (such as when a call is on hold).

Note: The corresponding global parameter is [SBCRTCPMode].

'Jitter Compensation'

sbc-jitter-compensation

[SBCJitterCompensation]

Enables the on-demand jitter buffer for SBC calls. The jitter buffer can be used when other functionality such as voice transcoding are not done on the call. The jitter buffer is useful when incoming packets are received at inconsistent intervals (i.e., packet delay variation). The jitter buffer stores the packets and sends them out at a constant rate (according to the coder's settings).

■ [0] Disable (default)
■ [1] Enable

Note:

■ The jitter buffer parameters, 'Dynamic Jitter Buffer Minimum Delay' (DJBufMinDelay) and 'Dynamic Jitter Buffer Optimization Factor' (DJBufOptFactor) can be used to configure minimum packet delay only when transcoding is employed.
■ This feature may require DSP resources. For more information, contact the sales representative of your purchased device.

'ICE Mode'

ice-mode

[SBCIceMode]

Enables Interactive Connectivity Establishment (ICE) for the SIP UA associated with the IP Profile. ICE is a methodology for NAT traversal, employing the Session Traversal Utilities for NAT (STUN) and Traversal Using Relays around NAT (TURN) protocols to provide a peer with a public IP address and port that can be used to connect to a remote peer. The device supports ICE-Full and ICE-Lite, but ICE-Lite is a limited implementation where the device can't initiate the ICE process.

ICE is typically required, for example, when the device operates in a Microsoft Teams Direct Routing (media bypass) environment.

■ [0] Disable (default)
■ [1] Lite = Enables ICE-Lite.
■ [2] Full = Enables ICE-Full.

For more information on ICE , see Implementing ICE for Media Sessions.

Note: As ICE has been defined by the WebRTC standard as mandatory, the support is important for deployments implementing WebRTC. For more information on WebRTC, see WebRTC.

'SDP Handle RTCP'

sbc-sdp-handle-rtcp

[SBCSDPHandleRTCPAttribute]

Enables the interworking of the RTCP attribute, 'a=rtcp' (RTCP) in the SDP, for the SIP UA associated with the IP Profile. The RTCP attribute is used to indicate the RTCP port for media when that port is not the next higher port number following the RTP port specified in the media line ('m=').

The parameter is useful for SIP entities that either require the attribute or do not support the attribute. For example, Google Chrome and Web RTC do not accept calls without the RTCP attribute in the SDP. In Web RTC, Chrome (SDES) generates the SDP with 'a=rtcp', for example:

m=audio 49170 RTP/AVP 0
a=rtcp:53020 IN IP6 2001:2345:6789:ABCD:EF01:2345:6789:ABCD

■ [0] Don't Care = (Default) The device forwards the SDP as is without interfering in the RTCP attribute (regardless if present or not).
■ [1] Add = The device adds the 'a=rtcp' attribute to the outgoing SDP offer sent to the SIP UA if the attribute was not present in the original incoming SDP offer.
■ [2] Remove = The device removes the 'a=rtcp' attribute, if present in the incoming SDP offer received from the other SIP UA, before sending the outgoing SDP offer to the SIP UA.

Note: As the RTCP attribute has been defined by the WebRTC standard as mandatory, the support is important for deployments implementing WebRTC. For more information on WebRTC, see WebRTC.

'RTCP Mux'

sbc-rtcp-mux

[SBCRTCPMux]

Enables interworking of multiplexing of RTP and RTCP onto a single local port, between SIP entities. The parameter enables multiplexing of RTP and RTCP traffic onto a single local port, for the SIP UA associated with the IP Profile.

Multiplexing of RTP data packets and RTCP packets onto a single local UDP port is done for each RTP session (according to RFC 5761). If multiplexing is not enabled, the device uses different (but adjacent) ports for RTP and RTCP packets.

With the increased use of NAT and firewalls, maintaining multiple NAT bindings can be costly and also complicate firewall administration since multiple ports must be opened to allow RTP traffic. To reduce these costs and session setup times, support for multiplexing RTP data packets and RTCP packets onto a single port is advantageous.

For multiplexing, the initial SDP offer must include the "a=rtcp-mux" attribute to request multiplexing of RTP and RTCP onto a single port. If the SDP answer wishes to multiplex RTP and RTCP, it must also include the "a=rtcp-mux" attribute. If the answer doesn't include the attribute, the offerer must not multiplex RTP and RTCP packets. If both ICE and multiplexed RTP-RTCP are used, the initial SDP offer must also include the "a=candidate:" attribute for both RTP and RTCP along with the "a=rtcp:" attribute, indicating a fallback port for RTCP in case the answerer doesn't support RTP and RTCP multiplexing.

■ [0] Not Supported = (Default) RTP and RTCP packets use different ports.
■ [1] Supported = Device multiplexes RTP and RTCP packets onto a single port.

Note: As RTP multiplexing has been defined by the WebRTC standard as mandatory, the support is important for deployments implementing WebRTC. For more information on WebRTC, see WebRTC.

'RTCP Feedback'

sbc-rtcp-feedback

[SBCRTCPFeedback]

Enables RTCP-based feedback indication in outgoing SDPs sent to the SIP UA associated with the IP Profile.

The parameter supports indication of RTCP-based feedback, according to RFC 5124, during RTP profile negotiation between two communicating SIP entities. RFC 5124 defines an RTP profile (S)AVPF for (secure) real-time communications to provide timely feedback from the receivers to a sender. For more information on RFC 5124, see http://tools.ietf.org/html/rfc5124.

Some SIP entities may require RTP secure-profile feedback negotiation (AVPF/SAVPF) in the SDP offer/answer exchange, while other SIP entities may not support it. The device indicates whether or not feedback is supported on behalf of the SIP UA. It does this by adding an "F" or removing the "F" from the SDP media line ('m=') for AVP and SAVP. For example, the following shows "AVP" appended with an "F", indicating that the SIP UA is capable of receiving feedback

m=audio 49170 RTP/SAVPF 0 96

■ [0] Feedback Off = (Default) The device doesn't send the feedback flag ("F") in SDP offers/answers that are sent to the SIP UA. If the SDP 'm=' attribute of an incoming message that is destined to the SIP UA includes the feedback flag, the device removes it before sending the message to the SIP UA.
■ [1] Feedback On = The device includes the feedback flag ("F") in the SDP offer sent to the SIP UA. The device includes the feedback flag in the SDP answer sent to the SIP UA only if it was present in the SDP offer received from the other SIP UA.
■ [2] As Is = The device doesn't involve itself in the feedback, but simply forwards any feedback indication as is.

Note:

■ As RTCP-based feedback has been defined by the WebRTC standard as mandatory, the support is important for deployments implementing WebRTC. For more information on WebRTC, see WebRTC.
■ RTCP-based feedback is required for the VoIPerfect feature (see VoIPerfect).

'Re-number MID'

sbc-renumber-mid

[SBCRenumberMID]

Enables the device to change the value of the 'a=mid:n' attribute (where n is a unique value) in the outgoing SDP offer so that in the first media ('m=' line) the value will be 0, the next media the value will be 1, and so on. This is done only if the 'a=mid' attribute is present in the incoming SDP offer.

■ [0] Disable (default)
■ [1] Enable

Note:

■ For deployments implementing WebRTC (see WebRTC), it's recommended that you configure the parameter to Enable.

'Voice Quality Enhancement'

sbc-voice-quality-enhancement

[SBCVoiceQualityEnhancement]

Enables the device to detect speech and network quality (packet loss and bandwidth reduction) and triggers the device to overcome the adverse conditions to ensure high call quality.

■ [0] Disable (default)
■ [1] Enable

Note: The parameter is applicable only to the VoIPerfect feature (see VoIPerfect).

'Switch Coder Upon Voice Quality'

switch-coder-upon-voice-quality

[SwitchCoderUponVoiceQuality]

Enables the device to detect poor voice quality during a call for an unregistered user, and then to change IP Profiles so that the coder switches between G.711 and Opus.

■ [0] Disable (default)
■ [1] Enable

For more information, see Configuring Voice Quality for Unregistered Users.

'Max Opus Bandwidth'

sbc-max-opus-bandwidth

[SBCMaxOpusBW]

Defines the VoIPerfect mode of operation, which is based on the Opus coder.

■ 0 = (Default) Managed Opus
■ 80000 = Smart Transcoding

Note: The parameter is applicable only to the VoIPerfect feature (see VoIPerfect).

'Generate No-Op Packets'

sbc-generate-noop

[SBCGenerateNoOp]

Enables the device to send RTP or T.38 No-Op packets during RTP or T.38 silence periods.

■ [0] Disable (default)
■ [1] Enable

For more information on No-Op packets, see No-Op Packets.

'SBC Multiple Coders'

configure voip > coders-and-profiles ip-profile > sbc-multiple-coders

[SBCMultipleCoders]

Defines if the UA associated with this IP Profile supports multiple coders in the SDP answer that is received from the peer side.

■ [0] Not Supported = (Default) If multiple coders ('m=' line) are present in the SDP answer received from the peer side, the device uses only the first supported coder in the list for the RTP media.
■ [1] Supported = If multiple coders ('m=' line) are present in the SDP answer received from the peer side, the device does one of the following, depending on whether DSP resources are required (e.g., for DTMF transcoding):
✔ DSP resources required: Upon receipt of the SDP answer, the device sends a re-INVITE message with only a single coder (first supported coder in the list) to the UA associated with this IP Profile. In other words, the device “forces” the UAs to negotiate only a single coder for the RTP media.
✔ DSP resources not required: The device supports multiple coders in the SDP answer, allowing the RTP media to use any one of the listed coders (doesn’t send a re-INVITE).

'SBC Allow Only Negotiated PT'

configure voip > coders-and-profiles ip-profile > sbc-allow-only-negotiated-pt

[SBCAllowOnlyNegotiatedPT]

Enables the device to allow only media (RTP) packets, from the UA associated with this IP Profile, using the single coder (payload type) that was negotiated during the SDP offer/answer exchange (e.g., 'm=audio 53456 RTP/AVP 0' for G.711). The device drops all other packets from the UA using any other coder.

■ [0] Disable =(Default) The device allows packets with multiple negotiated coders.
■ [1] Enable = The device allows only packets with the single negotiated coder.

'Remove CSRC'

sbc-remove-csrc

[SBCRemoveCSRC]

Enables the device to remove the contributing source (CSRC) identifiers (CC field) from the RTP header in RTP packets sent to the UA associated with this IP Profile.

■ [0] Disable (Default)
■ [1] Enable

'SBC Precondition'

sbc-precondition

[SBCPrecondition]

Defines if the UA associated with this IP Profile supports SIP session preconditions according to RFC 3312.

■ [0] Not Supported = (Default) If the Require header in the incoming SIP message contains the value 'precondition', the device rejects the message (420 Bad Extension response). The device never adds the value 'precondition' to the Supported header (or Require header) in outgoing messages.
■ [1] Supported = The device always adds the value 'precondition' to the Supported header in the outgoing SIP message (unless it has to add it to the Require header according to RFC 3312).

Note:

■ For this functionality, you must also do the following:
✔ Configure the IP Profile's 'Remote Can Play Ringback' parameter to No because according to the RFC, the 'precondition' must be done during the early media stage.
✔ Configure the IP Profile's 'SIP UPDATE Support' parameter to Supported because using the SIP UPDATE message is mandatory according to the RFC.
■ The device doesn't initiate precondition attributes in the SDP.

'Enhanced PLC'

sbc-enhanced-plc

[SBCEnhancedPlc]

Enables packet loss concealment (PLC) when this IP Profile uses the G.711 voice coder with 20-msec packet interval. PLC is used to mask the effects of lost or discarded packets. Therefore, enabling PLC enhances the device's Quality of Experience (QoE) capabilities by improving MOS scores when packet loss ratio is less than 10%.

■ [0] Disable (default)
■ [1] Enable

Note: This feature requires DSP resources.

Quality of Service

'RTP IP DiffServ'

rtp-ip-diffserv

[IPDiffServ]

Defines the DiffServ value for Premium Media class of service (CoS) content.

The valid range is 0 to 63. The default is 46.

Note:

■ The corresponding global parameter is [PremiumServiceClassMediaDiffServ].
■ In addition to audio, the parameter applies to video media if the 'RTP Video DiffServ' is configured to -1 (default).

'RTP Video DiffServ'

rtp-video-diffserv

[VideoDiffServ]

Defines the DiffServ value for video media.

The valid range is -1, or 0 to 63. The default is -1, which means the DiffServ value for video is according to the 'RTP IP DiffServ' parameter.

'Signaling DiffServ'

signaling-diffserv

[SigIPDiffServ]

Defines the DiffServ value for Premium Control CoS content (Call Control applications).

The valid range is 0 to 63. The default is 40.

Note: The corresponding global parameter is [PremiumServiceClassControlDiffServ].

'Data DiffServ'

data-diffserv

[DataDiffServ]

Defines the DiffServ value of MSRP traffic in the IP header's DSCP field.

The valid range is 0 to 63. The default is 0.

For more information on MSRP, see Configuring Message Session Relay Protocol.

SBC Signaling

'PRACK Mode'

sbc-prack-mode

[SbcPrackMode]

Defines the device's handling of SIP PRACK messages for the SIP UA associated with the IP Profile.

■ [0] Disabled = The device doesn’t allow PRACK:
✔ For SIP requests (INVITE) and responses (18x), the device removes the ‘100rel’ option from the SIP Supported header (if present). In other words, the device disables PRACK with this SIP UA.
✔ If the device receives an INVITE message containing the header and value ‘Require: 100rel’, it rejects the message (with a SIP 420 response).
✔ If the device receives a SIP 18x response containing the RSeq header and the ‘100rel’ option, it sends a CANCEL message to cancel the SIP dialog.
■ [1] Optional = PRACK is optional. If required, the device performs the PRACK process on behalf of the SIP UA.
■ [2] Mandatory = PRACK is required for this SIP UA. Calls from UAs that do not support PRACK are rejected. Calls destined to these UAs are also required to support PRACK.
■ [3] Transparent = (Default) The device doesn't intervene with the PRACK process and forwards the request as is.
■ [4] Optional With Adaptations = This option may be useful, for example, to prevent PRACK congestion caused by the flooding of the device with 18x messages without body.
✔ Outgoing INVITE messages (sent to SIP UA):
- The device adds the header ‘Supported: 100rel’ to the INVITE message. If the message included the header and value ‘Require: 100rel’, it removes the ‘100rel’ option.
- If the device adds the ‘100rel’ option, it terminates and fully handles PRACK; otherwise, the device forwards the message transparently.
✔ Incoming INVITE messages (from SIP UA):
- If the message doesn’t contain the ‘100rel’ option, the device doesn’t handle PRACK.
- If the message contains the header and value ‘Require: 100rel’, the device processes PRACK as described for the Mandatory optional value above (and terminates PRACK, if necessary).
- If the message contains the header and value ‘Supported: 100rel’, the device activates PRACK Extensions as follows:
>> If the device sends an outgoing 18x responses with body (e.g., SDP), the device processes PRACK as described for the Mandatory optional value above (and terminates PRACK, if necessary).
>> If the device sends an outgoing 18x responses without body, the device removes the ‘100rel’ option and the RSeq header (if present). If the RSeq header was present, the device sends a terminated PRACK to the incoming leg without Optional With Adaptations outgoing leg involvement.

'P-Asserted-Identity Header Mode'

sbc-assert-identity

[SBCAssertIdentity]

Defines the device's handling of the SIP P-Asserted-Identity header for the SIP UA associated with the IP Profile. This header indicates how the outgoing SIP message asserts identity.

■ [0] As Is = (Default) P-Asserted Identity header is not affected and the device uses the same P-Asserted-Identity header (if present) in the incoming message for the outgoing message.
■ [1] Add = Adds a P-Asserted-Identity header. The header's values are taken from the source URL.
■ [2] Remove = Removes the P-Asserted-Identity header.

Note:

■ The parameter affects only initial INVITE requests.
■ The corresponding global parameter is [SBCAssertIdentity].

'Diversion Header Mode'

sbc-diversion-mode

[SBCDiversionMode]

Defines the device’s handling of the SIP Diversion header for the SIP UA associated with the IP Profile.

■ [0] As Is = (Default) Diversion header is not handled.
■ [1] Add = History-Info header is converted to a Diversion header.
■ [2] Remove = Removes the Diversion header and the conversion to the History-Info header depends on the SBCHistoryInfoMode parameter.

For more information on interworking of the History-Info and Diversion headers, see Interworking SIP Diversion and History-Info Headers.

Note:

■ If the Diversion header is used, you can specify the URI type (e.g., "tel:") to use in the header, using the [SBCDiversionUriType] parameter.

'History-Info Header Mode'

sbc-history-info-mode

[SBCHistoryInfoMode]

Defines the device’s handling of the SIP History-Info header for the SIP UA associated with the IP Profile.

■ [0] As Is = (Default) History-Info header is not handled.
■ [1] Add = Diversion header is converted to a History-Info header.
■ [2] Remove = History-Info header is removed from the SIP dialog and the conversion to the Diversion header depends on the SBCDiversionMode parameter.

For more information on interworking of the History-Info and Diversion headers, see Interworking SIP Diversion and History-Info Headers.

'Session Expires Mode'

sbc-session-expires-mode

[SBCSessionExpiresMode]

Defines the required session expires mode for the SIP UA associated with the IP Profile.

■ [0] Transparent = (Default) The device doesn't interfere with the session expires negotiation.
■ [1] Observer = If the SIP Session-Expires header is present, the device doesn't interfere, but maintains an independent timer for each leg to monitor the session. However, if the session is not refreshed on time, the device disconnects the call. The timer duration is configured by the global parameter [SipSessionExpiresObserverMode].
■ [2] Not Supported = The device doesn't allow a session timer with this SIP UA.
■ [3] Supported = The device enables the session timer with this SIP UA. If the incoming SIP message doesn't include any session timers, the device adds the session timer information to the sent message. You can configure the value of the Session-Expires and Min-SE headers, using the [SBCSessionExpires] and [SBCMinSE] parameters, respectively.

'SIP UPDATE Support'

sbc-rmt-update-supp

[SBCRemoteUpdateSupport]

Defines if the SIP UA associated with this IP Profile supports the receipt of SIP UPDATE messages.

■ [0] Not Supported = The UA doesn't support the receipt of UPDATE messages.
■ [1] Supported Only After Connect = The UA supports the receipt of UPDATE messages, but only after the call is connected.
■ [2] Supported = (Default) The UA supports the receipt of UPDATE messages during call setup and after call establishment.
■ [3] According Remote Allow = The UA support for SIP UPDATE messages depends on the presence of the "update" capability in the Allow header in the last SIP message received from the UA. When the UA indicates UPDATE support:
✔ If session refresh is used, the device sends session refreshes to the UA using UPDATE messages.
✔ If an UPDATE message is received from a peer UA, the device forwards the UPDATE message to this supporting UA.
✔ If a re-INVITE message containing an SDP is received from a peer UA, the device sends it as an UPDATE message to the supporting UA. If an INVITE message without an SDP is received from a peer UA, the device forwards the INVITE message to the supporting UA.

If the Allow header doesn't indicate UPDATE support, the device sends INVITE messages instead of UPDATE messages to the UA.

'Remote re-INVITE'

sbc-rmt-re-invite-supp

[SBCRemoteReinviteSupport]

Defines if the SIP UA associated with this IP Profile supports the receipt of SIP re-INVITE messages.

■ [0] Not Supported = The UA doesn't support the receipt of re-INVITE messages. If the device receives a re-INVITE from another UA that is destined to this UA, the device "terminates" the re-INVITE and sends a SIP response to the UA that sent it, which can be a success or a failure, depending on whether the device can bridge the media between the UAs.
■ [1] Supported only with SDP = The UA supports the receipt of re-INVITE messages, but only if they contain an SDP body. If the incoming re-INVITE from another UA doesn't contain SDP, the device creates and adds an SDP body to the re-INVITE that it forwards to the UA.
■ [2] Supported = (Default) The UA supports the receipt of re-INVITE messages with or without SDP.

'Remote Delayed Offer Support'

sbc-rmt-delayed-offer

[SBCRemoteDelayedOfferSupport]

Defines if the remote UA supports delayed offer (i.e., initial INVITE requests without an SDP offer).

■ [0] Not Supported
■ [1] Supported (default)

Note:

■ For the parameter to function, you need to assign extension coders to the IP Profile of the SIP UA that doesn't support delayed offer (using the 'Extension Coders Group' parameter).

'MSRP re-INVITE/UPDATE'

sbc-msrp-re-invite-update-supp

[SBCMSRPReinviteUpdateSupport]

Defines if the SIP UA (MSRP endpoint) associated with this IP Profile supports the receipt of re-INVITE and UPDATE SIP messages.

■ [0] Not Supported = The device doesn't send re-INVITE or UPDATE messages to the UA. If the device receives any of these messages from the peer UA, the device "terminates" the messages, and then sends a SIP response to the peer UA on behalf of the UA associated with this IP Profile.
■ [1] Supported (default)

For more information on MSRP, see Configuring Message Session Relay Protocol.

'MSRP Offer Setup Role'

sbc-msrp-offer-setup-role

[SBCMSRPOfferSetupRole]

Defines the device's preferred MSRP role, which is indicated in the initial SDP offer that it sends to the destination MSRP endpoint ('a=setup' line) associated with this IP Profile. However, this is only a preferred role; the actual role that the device takes on depends on the destination MSRP endpoint’s desired role, which is indicated in the SDP answer in its reply to the device:

■ If 'a=setup:active’, the device takes the passive role.
■ If 'a=setup:passive', the device takes the active role.
■ If 'a=setup' (i.e., empty) or no ‘a=setup’, the device takes the active role.

The possible values include:

■ [0] Active = The device prefers the active role and includes 'a=setup:active' in the outgoing SDP offer sent to the endpoint associated with the IP Profile.
■ [1] Passive = The device prefers the passive role and includes 'a=setup:passive' in the outgoing SDP offer sent to the endpoint associated with the IP Profile.
■ [2] ActPass = (Default) The device has no role preference and includes 'a=setup:actpass' in the outgoing SDP offer sent to the endpoint associated with the IP Profile

For more information on MSRP, see Configuring Message Session Relay Protocol.

'MSRP Empty Message Format'

sbc-msrp-empty-message-format

[SBCMSRPEmpMsg]

On an active MSRP leg, enables the device to add the Content-Type header to the first empty (i.e., no body) MSRP message that is used to initiate the MSRP connection.

■ [0] Default = (Default) Sends the empty message with regular headers, according to the RFC for MSRP.
■ [1] With Content Type = Adds the Content-Type header to the empty message (in addition to the regular headers according to the RFC for MSRP).

For more information on MSRP, see Configuring Message Session Relay Protocol.

'Remote Representation Mode'

sbc-rmt-rprsntation

[SBCRemoteRepresentationMode]

Enables interworking SIP in-dialog, Contact and Record-Route headers between SIP entities. The parameter defines the device's handling of in-dialog, Contact and Record-Route headers for messages sent to the SIP UA associated with the IP Profile.

■ [-1] According to Operation Mode = (Default) Depends on the setting of the 'Operation Mode' parameter in the IP Groups or SRDs table:
✔ B2BUA: Device operates as if the parameter is set to Replace Contact [0].
✔ Call State-full Proxy: Device operates as if the parameter is set to Add Routing Headers [1].
■ [0] Replace Contact = The URI host part in the Contact header of the received message (from the other side) is replaced with the device's address or with the value of the 'SIP Group Name' parameter (configured in the IP Groups table) in the outgoing message sent to the SIP UA.
■ [1] Add Routing Headers = Device adds a Record-Route header for itself to outgoing messages (requests\responses) sent to the SIP UA in dialog-setup transactions. The Contact header remains unchanged.
■ [2] Transparent = Device doesn't change the Contact header and doesn't add a Record-Route header for itself. Instead, it relies on its' own inherent mechanism to remain in the route of future requests in the dialog (for example, relying on the way the endpoints are set up or on TLS as the transport type).

'Keep Incoming Via Headers'

sbc-keep-via-headers

[SBCKeepVIAHeaders]

Enables interworking SIP Via headers between SIP entities. The parameter defines the device's handling of Via headers for messages sent to the SIP UA associated with the IP Profile.

■ [-1] According to Operation Mode = Depends on the setting of the 'Operation Mode' parameter in the IP Groups table or SRDs table:
✔ B2BUA: Device operates as if the parameter is set to Disable [0].
✔ Call State-full Proxy: Device operates as if the parameter is set to Enable [1].
■ [0] Disable = Device removes all Via headers received in the incoming SIP request from the other leg and adds a Via header identifying only itself, in the outgoing message sent to the SIP UA.
■ [1] Enable = Device retains the Via headers received in the incoming SIP request and adds itself as the top-most listed Via header in the outgoing message sent to the SIP UA.

'Keep Incoming Routing Headers'

sbc-keep-routing-headers

[SBCKeepRoutingHeaders]

Enables interworking SIP Record-Route headers between SIP entities. The parameter defines the device's handling of Record-Route headers for request/response messages sent to the SIP UA associated with the IP Profile.

■ [-1] According to Operation Mode = (Default) Depends on the setting of the 'Operation Mode' in the IP Group or SRDs table:
✔ B2BUA: Device operates as if the parameter is set to Disable [0].
✔ Call State-full Proxy: Device operates as if the parameter is set to Enable [1].
■ [0] Disable = Device removes the Record-Route headers received in requests and responses from the other side, in the outgoing SIP message sent to the SIP UA. The device creates a route set for that side of the dialog based on these headers, but doesn't send them to the SIP UA.
■ [1] Enable = Device retains the incoming Record-Route headers received in requests and non-failure responses from the other side, in the following scenarios:
✔ The message is part of a SIP dialog-setup transaction.
✔ The messages in the setup and previous transaction didn't include the Record-Route header, and therefore hadn't set the route set.

Note: Record-Routes are kept only for SIP INVITE, UPDATE, SUBSCRIBE and REFER messages.

'Keep User-Agent Header'

sbc-keep-user-agent

[SBCKeepUserAgentHeader]

Enables interworking SIP User-Agent headers between SIP entities. The parameter defines the device's handling of User-Agent headers for response/request messages sent to the SIP UA associated with the IP Profile.

■ [-1] According to Operation Mode = (Default) Depends on the setting of the 'Operation Mode' parameter in the IP Group or SRDs table:
✔ B2BUA: Device operates as if this parameter is set to Disable [0].
✔ Call State-full Proxy: Device operates as if this parameter is set to Enable [1].
■ [0] Disable = Device removes the User-Agent/Server headers received in the incoming message from the other side, and adds its' own User-Agent header in the outgoing message sent to the SIP UA.
■ [1] Enable = Device retains the User-Agent/Server headers received in the incoming message and sends the headers as is in the outgoing message to the SIP UA.

'Use Initial Incoming INVITE for re-INVITE'

use-initial-incoming-invite-for-reinvite

[KeepInitialIncomingINVITE]

Enables the device to use the initial (first) incoming SIP INVITE message of the dialog session, for creating a re-INVITE message. For example, if the device receives a REFER message (call transfer), it terminates the message locally, creates a re-INVITE based on the initial INVITE, and then sends it to the peer side. This may be useful if the initial incoming SIP INVITE includes customized headers or bodies that you want to preserve for the outgoing INVITE.

■ [0] Disable (default)
■ [1] Enable

'Handle X-Detect'

sbc-handle-xdetect

[SBCHandleXDetect]

Enables the detection and notification of events (AMD, CPT, and fax), using the X-Detect SIP header.

■ [0] No (default)
■ [1] Yes

For more information, see Event Detection and Notification using X-Detect Header.

'ISUP Body Handling'

sbc-isup-body-handling

[SBCISUPBodyHandling]

Defines the handling of ISUP data for interworking SIP and SIP-I endpoints.

■ [0] Transparent = (Default) ISUP data is passed transparently (as is) between endpoints (SIP-I to SIP-I calls).
■ [1] Remove = ISUP body is removed from INVITE messages.
■ [2] Create = ISUP body is added to outgoing INVITE messages.
■ [3] Create If Not Exists = ISUP body is added to outgoing INVITE messages if it doesn't exist in the incoming leg. If it exists, unknown fields and messages by the device are passed transparently, while known fields can be manipulated using Message Manipulation rules. For known fields, some values that are "reserved for national use" may be changed to default.

For more information on interworking SIP and SIP-I, see Interworking SIP and SIP-I Endpoints.

'ISUP Variant'

sbc-isup-variant

[SBCISUPVariant]

Defines the ISUP variant for interworking SIP and SIP-I endpoints.

■ [0] itu92 = (Default) ITU 92 variant
■ [1] Spirou = SPIROU (ISUP France)

'Max Call Duration'

sbc-max-call-duration

[SBCMaxCallDuration]

Defines the maximum duration (in minutes) per SBC call that is associated with the IP Profile. If the duration is reached, the device ends the call.

The valid range is 0 to 35,791, where 0 means unlimited call duration. The default is the value configured for the global parameter [SBCMaxCallDuration].

SBC Registration

'User Registration Time'

sbc-usr-reg-time

[SBCUserRegistrationTime]

Defines the registration time (in seconds) that the device responds to SIP REGISTER requests from users belonging to the SIP UA associated with the IP Profile. The registration time is inserted in the Expires header in the outgoing response sent to the user.

The Expires header determines the lifespan of the registration. For example, a value of 3600 means that the registration will timeout in one hour and at that point, the user will not be able to make or receive calls.

The valid range is 0 to 2,000,000. The default is 0. If configured to 0, the Expires header's value received in the user’s REGISTER request remains unchanged. If no Expires header is received in the REGISTER message and the parameter is set to 0, the Expires header's value is set to 180 seconds, by default.

Note:

■ The corresponding global parameter is [SBCUserRegistrationTime].

'NAT UDP Registration Time'

sbc-usr-udp-nat-reg-time

[SBCUserBehindUdpNATRegistrationTime]

Defines the registration time (in seconds) that the device includes in register responses, in response to SIP REGISTER requests from users belonging to the SIP UA associated with the IP Profile.

The parameter applies only to users that are located behind NAT and whose communication type is UDP. The registration time is inserted in the Expires header in the outgoing response sent to the user.

The Expires header determines the lifespan of the registration. For example, a value of 3600 means that the registration will timeout in one hour, unless the user sends a refresh REGISTER before the timeout. Upon timeout, the device removes the user’s details from the registration database, and the user will not be able to make or receive calls through the device.

The valid value is 0 to 2,000,000. If configured to 0, the Expires header's value received in the user’s REGISTER request remains unchanged. By default, no value is defined (-1).

Note:

■ If the parameter is not configured, the registration time is according to the global parameter SBCUserRegistrationTime or IP Profile parameter 'User Registration Time'.

'NAT TCP Registration Time'

sbc-usr-tcp-nat-reg-time

[SBCUserBehindTcpNATRegistrationTime]

Defines the registration time (in seconds) that the device includes in register responses, in response to SIP REGISTER requests from users belonging to the SIP UA associated with the IP Profile.

The parameter applies only to users that are located behind NAT and whose communication type is TCP. The registration time is inserted in the Expires header in the outgoing response sent to the user.

The Expires header determines the lifespan of the registration. For example, a value of 3600 means that the registration will timeout in one hour, unless the user sends a refresh REGISTER before the timeout. Upon timeout, the device removes the user’s details from the registration database, and the user will not be able to make or receive calls through the device.

The valid value is 0 to 2,000,000. If configured to 0, the Expires header's value received in the user’s REGISTER request remains unchanged. By default, no value is defined (-1).

Note:

■ If the parameter is not configured, the registration time is according to the global parameter SBCUserRegistrationTime or IP Profile parameter 'User Registration Time'.

SBC Forward and Transfer

'Remote REFER Mode'

sbc-rmt-refer-behavior

[SBCRemoteReferBehavior]

Defines the device's handling of SIP REFER requests for the SIP UA (transferee - call party that is transfered to the transfer target) associated with the IP Profile.

■ [0] Regular = (Default) SIP Refer-To header value is unchanged and the device forwards the REFER message as is. However, if you configure the 'Remote Replaces Mode' parameter (see below) to any value other than Keep as is, the device may modify the URI of the Refer-To header to reflect the call identifiers of the leg.
■ [1] Database URL = SIP Refer-To header value is changed so that the re-routed INVITE is sent through the device:
a. Before forwarding the REFER request, the device changes the host part to the device's IP address and adds the prefix "T~&R_" to the Contact user part.
b. The incoming INVITE is identified as a REFER-resultant INVITE according to this special prefix.
c. The device replaces the host part in the Request-URI with the host from the REFER contact. The special prefix remains in the user part for regular classification, manipulation, and routing. The special prefix can also be used for specific routing rules for REFER-resultant INVITEs.
d. The special prefix is removed before the resultant INVITE is sent to the destination (transfer target).
■ [2] IP Group Name = Changes the host part in the REFER message to the value that you configured for the 'SIP Group Name' parameter in the IP Groups table (see Configuring IP Groups).
■ [3] Handle Locally = Handles the incoming REFER request itself without forwarding the REFER. The device generates a new INVITE to the alternative destination (transfer target) according to the rules in the IP-to-IP Routing table (the 'Call Trigger' parameter must be set to REFER).
■ [4] Local Host = In the REFER message received from the transferor, the device replaces the Refer-To header value (URL) with the IP address of the device or with the ‘Local Host Name’ parameter value configured for the IP Group (transferee) to where the device forwards the REFER message. This ensures that the transferee sends the re-routed INVITE back to the device which then sends the call to the transfer target.
■ [5] Keep URI (user@host) = The device forwards the REFER message without changing the URI (user@host) in the SIP Refer-To header. If you configure the 'Remote Replaces Mode' parameter (see below) to any value other than Keep as is, the devicemay modify the 'replaces' parameter of the Refer-To header to reflect the call identifiers of the leg. This applies to all types of call transfers (e.g., blind and attendant transfer).

Note:

■ You can override the parameter's settings using Message Manipulation rules configured with the AudioCodes proprietary SIP header, X-AC-Action. For more information, see Using Proprietary SIP X-AC-Action Header.
■ The corresponding global parameter is [SBCReferBehavior].
■ For MSRP sessions, the Handle Locally option is not applicable. For more information on MSRP sessions, see Configuring Message Session Relay Protocol.

'Remote Replaces Mode'

sbc-rmt-replaces-behavior

[SBCRemoteReplacesBehavior]

Enables the device to handle incoming INVITEs containing the Replaces header for the SIP UA (which doesn't support the header) associated with the IP Profile. The Replaces header is used to replace an existing SIP dialog with a new dialog such as in call transfer or call pickup.

■ [0] Standard = (Default) The SIP UA supports INVITE messages containing Replaces headers. The device forwards the INVITE message containing the Replaces header to the SIP UA. The device may change the value of the Replaces header to reflect the call identifiers of the leg.
■ [1] Handle Locally = The SIP UA doesn't support INVITE messages containing Replaces headers. The device terminates the received INVITE containing the Replaces header and establishes a new call between the SIP UA and the new call party. It then disconnects the call with the initial call party, by sending it a SIP BYE request.
■ [2] Keep as is = The SIP UA supports INVITE messages containing Replaces headers. The device forwards the Replaces header as is in incoming REFER and outgoing INVITE messages from/to the SIP UA (i.e., Replaces header's value is unchanged).

For example, assume that the device establishes a call between A and B. If B initiates a call transfer to C, the device receives an INVITE with the Replaces header from C. If A supports the Replaces header, the device simply forwards the INVITE as is to A; a new call is established between A and C and the call between A and B is disconnected. However, if A doesn't support the Replaces header, the device uses this feature to terminate the INVITE with Replaces header and handles the transfer for A. The device does this by connecting A to C, and disconnecting the call between A and B, by sending a SIP BYE request to B. Note that if media transcoding is required, the device sends an INVITE to C on behalf of A with a new SDP offer.

'Play RBT To Transferee'

sbc-play-rbt-to-xferee

[SBCPlayRBTToTransferee]

Enables the device to play a ringback tone to the transferred party (transferee) during a blind call transfer, for the SIP UA associated with the IP Profile (which doesn't support such a tone generation during call transfer). The ringback tone indicates to the transferee of the ringing of the transfer target (to where the transferee is being transferred).

■ [0] No (Default)
■ [1] Yes

Typically, the transferee hears a ringback tone only if the transfer target sends it early media. However, if the transferee is put on-hold before being transferred, no ringback tone is heard.

When this feature is enabled, the device generates a ringback tone to the transferee during call transfer in the following scenarios:

■ Transfer target sends a SIP 180 (Ringing) to the device.
■ For non-blind transfer, if the call is transferred while the transfer target is ringing and no early media occurs.
■ The 'Remote Early Media RTP Behavior parameter is set to Delayed (used in the Skype for Business environment), and transfer target sends a 183 Session Progress with SDP offer. If early media from the transfer target has already been detected, the transferee receives RTP stream from the transfer target. If it has not been detected, the device generates a ringback tone to the transferee and stops the tone generation once RTP has been detected from the transfer target.

For any of these scenarios, if the transferee is put on-hold by the transferor, the device retrieves the transferee from hold, sends a re-INVITE if necessary, and then plays the ringback tone.

Note:

■ For the device to play the ringback tone, it must be loaded with a Prerecorded Tones (PRT) file. For more information, see Prerecorded Tones File.

'Remote 3xx Mode'

sbc-rmt-3xx-behavior

[SBCRemote3xxBehavior]

Defines the device's handling of SIP 3xx redirect responses for the SIP UA associated with the IP Profile. By default, the device's handling of SIP 3xx responses is to send the Contact header unchanged. However, some SIP entities may support different versions of the SIP 3xx standard while others may not even support SIP 3xx.

When enabled, the device handles SIP redirections between different subnets (e.g., between LAN and WAN sides). This is required when the new address provided by the redirector (Redirect sever) may not be reachable by the far-end user (FEU) located in another subnet. For example, a far-end user (FEU) in the WAN sends a SIP request via the device to a Redirect server in the LAN, and the Redirect server replies with a SIP 3xx response to a PBX in the LAN in the Contact header. If the device sends this response as is (i.e., with the original Contact header), the FEU is unable to reach the new destination.

■ [0] Transparent = (Default) The device forwards the received SIP 3xx response as is, without changing the Contact header (i.e., transparent handling).
■ [1] Database URL = The device changes the Contact header so that the re-route request is sent through the device. The device changes the URI in the Contact header of the received SIP 3xx response to its own URI and adds a special user prefix ("T~&R_”), which is then sent to the FEU. The FEU then sends a new INVITE to the device, which the device then sends to the correct destination.
■ [2] Handle Locally = The device handles SIP 3xx responses on behalf of the dialog-initiating UA and retries the request (e.g., INVITE) using one or more alternative URIs included in the 3xx response. The device sends the new request to the alternative destination according to the IP-to-IP Routing table (the 'Call Trigger' field must be set to 3xx).
■ [3] IP Group Name = If the 'SIP Group Name' parameter of the IP Group of the dialog-initiating UA is configured with a non-empty value, the device changes the host part of the Contact header in the 3xx response to this value, before forwarding the 3xx response to the dialog-initiating UA.
■ [4] Local Host = The device changes the host part of the Contact header in the 3xx response before forwarding the 3xx response to the dialog-initiating UA. If the 'Local Host Name' parameter of the IP Group of the dialog-initiating UA is configured with a non-empty value, the device changes the host part of the Contact header to this value. If the 'Local Host Name' is empty, the device changes the host part to the device's IP address (the same IP address used in the SIP Via and Contact headers of messages sent to the IP Group).

Note:

■ When the parameter is changed from Database URL to Transparent, new 3xx Contact headers remain unchanged. However, requests with the special prefix continue using the device's database to locate the new destination.
■ Optional values IP Group Name and Local Host are applicable only to 3xx responses received due to INVITE messages.
■ Only one database entry is supported for the same host, port, and transport combination. For example, the following URLs cannot be distinguished by the device:
✔ sip:10.10.10.10:5060;transport=tcp;param=a
✔ sip:10.10.10.10:5060;transport=tcp;param=b
■ The database entry expires two hours after the last use.
■ The maximum number of destinations (i.e., database entries) is 50.
■ The corresponding global parameter is [SBC3xxBehavior].

'Send Header for Transfer'

header-for-transfer

[HeaderForTransfer]

Enables the device to notify a change in the remote party (calling or called) after a call transfer (locally handled by the device).

The updated information is provided by adding a Remote-Party-ID header to the outgoing message (INVITE, UPDATE, or 200 OK). As the From header in the SIP dialogs throughout the call transfer process contains the URI of the initial call, the inclusion of the Remote-Party-ID header resolves the problem for identifying the new party.

The device also sets the fields in the Remote-Party-ID header to 'party=calling;privacy=off;screen=yes'. However, if a Remote-Party-ID header with 'party=calling' is already present in the incoming request or response, the device only updates the URI. If a Remote-Party-ID header is present in the incoming request or response, but with a different value for the 'party' parameter (e.g. 'party=called'), the device adds an additional Remote-Party-ID header as described above.

■ [0] None = (Default) The device doesn't add the Remote-Party-ID header (as explained above).
■ [1] Remote-Party-ID = The device adds the Remote-Party-ID header (as explained above).

SBC Hold

'Remote Hold Format'

remote-hold-Format

[SBCRemoteHoldFormat]

Defines the format of the SDP in the SIP re-INVITE (or UPDATE) for call hold that the device sends to the held party.

■ [0] Transparent = (Default) Device forwards SDP as is.
■ [1] Send Only = Device sends SDP with 'a=sendonly'.
■ [2] Send Only Zero Ip = Device sends SDP with 'a=sendonly' and 'c=0.0.0.0'.
■ [3] Inactive = Device sends SDP with 'a=inactive'.
■ [4] Inactive Zero Ip = Device sends SDP with 'a=inactive' and 'c=0.0.0.0'.
■ [5] Not Supported = This option can be used when the remote side doesn't support call hold. The device terminates call hold requests received on the leg interfacing with the initiator of the call hold, and replies to this initiator with a SIP 200 OK response. However, call retrieve (resume) requests received from the initiator are forwarded to the remote side. The device can play a held tone to the held party if the 'Play Held Tone' parameter is set to Internal.
■ [6] Hold and Retrieve Not Supported = This option can be used when the remote side doesn't support call hold and retrieve (resume). The device terminates call hold and call retrieve requests received on the leg interfacing with the initiator of the call hold/retrieve, and replies to this initiator with a SIP 200 OK response. Therefore, the device doesn't forward call hold and/or retrieve requests to the remote side.

'Reliable Held Tone Source'

reliable-heldtone-source

[ReliableHoldToneSource]

Enables the device to consider the received call-hold request (re-INVITE/UPDATE) with SDP containing 'a=sendonly', as genuine.

■ [0] No = (Default) Even if the received SDP contains 'a=sendonly', the device plays a held tone to the held party. This is useful in cases where the initiator of the call hold doesn't support the generation of held tones.
■ [1] Yes = If the received SDP contains 'a=sendonly', the device doesn't play a held tone to the held party (and assumes that the initiator of the call hold plays the held tone).

Note:

■ The device plays a held tone only if the 'Play Held Tone' parameter is set to Internal or External.

'Play Held Tone'

play-held-tone

[SBCPlayHeldTone]

Enables the device to play Music-on-Hold (MoH) to call parties that are placed on hold. This is useful if the held party doesn't support the play of a local hold tone, or for IP entities initiating call hold that do not support the generation of hold tones.

■ [0] No = (Default) The device doesn't play any tone to held call parties.
■ [1] Internal = Plays the local default hold tone or a tone defined in the PRT file (if installed).
■ [2] External = Plays MoH audio streams that originate from an external media source. For more information, see Configuring SBC MoH from External Media Source

Note:

■ If you configure the parameter to Internal, the device plays the tone only if the 'SBC Remote Hold Format' parameter is configured to one of the following: send-only, send only 0.0.0.0, not supported, or transparent (when the incoming SDP is 'sendonly').

SBC Fax

'Fax Coders Group'

sbc-fax-coders-group-name

[SBCFaxCodersGroupName]

Assigns a Coder Group which defines the supported fax coders for fax negotiation for the SIP UA associated with the IP Profile. To configure Coder Groups, see Configuring Coder Groups.

Note: The parameter is applicable only if you configure the 'Fax Mode' parameter to a value other than As Is.

'Fax Mode'

sbc-fax-behavior

[SBCFaxBehavior]

Enables the device to handle fax offer-answer negotiations for the SIP UA associated with the IP Profile.

■ [0] As Is = (Default) Device forwards fax transparently, without interference.
■ [1] Handle always = Handle fax according to fax settings in the IP Profile for all offer-answer transactions (including the initial INVITE).
■ [2] Handle on re-INVITE = Handle fax according to fax settings in the IP Profile for all re-INVITE offer-answer transactions (except for initial INVITE).

Note: The fax settings in the IP Profile include 'Fax Coders Group', 'Fax Offer Mode', and 'Fax Answer Mode'.

'Fax Offer Mode'

sbc-fax-offer-mode

[SBCFaxOfferMode]

Defines the coders included in the outgoing SDP offer (sent to the called "fax") for the SIP UA associated with the IP Profile.

■ [0] All coders = (Default) Use only (and all) the coders of the selected Coder Group, configured using the SBCFaxCodersGroupID parameter.
■ [1] Single coder = Use only one coder. If a coder in the incoming offer (from the calling "fax") matches a coder in the SBCFaxCodersGroupID, the device uses this coder. If no match exists, the device uses the first coder listed in the Coders Group ID (SBCFaxCodersGroupID).

Note: The parameter is applicable only if you configure the 'Fax Mode' parameter to a value other than As Is.

'Fax Answer Mode'

sbc-fax-answer-mode

[SBCFaxAnswerMode]

Defines the coders included in the outgoing SDP answer (sent to the calling "fax") for the SIP UA associated with the IP Profile.

■ [0] All coders = Use matched coders between the incoming offer coders (from the calling "fax") and the coders of the selected Coder Group (configured using the SBCFaxCodersGroupID parameter).
■ [1] Single coder = (Default) Use only one coder. If the incoming answer (from the called "fax") includes a coder that matches a coder match between the incoming offer coders (from the calling "fax") and the coders of the selected Coder Group (SBCFaxCodersGroupID, then the device uses this coder. If no match exists, the device uses the first listed coder of the matched coders between the incoming offer coders (from the calling "fax") and the coders of the selected Coder Group.

Note: The parameter is applicable only if you configure the 'Fax Mode' parameter to a value other than As Is.

'Remote Renegotiate on Fax Detection'

sbc-rmt-renegotiate-on-fax-detect

[SBCRemoteRenegotiateOnFaxDetection]

Enables local handling of fax detection and negotiation by the device on behalf of the SIP UA associated with the IP Profile. This applies to faxes sent immediately upon the establishment of a voice channel (i.e., after 200 OK).

The device attempts to detect the fax (CNG tone) from the originating SIP UA within a user-defined interval (see the SBCFaxDetectionTimeout parameter) immediately after the voice call is established.

Once fax is detected, the device can handle the subsequent fax negotiation by sending re-INVITE messages to both SIP entities. The device also negotiates the fax coders between the two SIP entities. The negotiated coders are according to the list of fax coders assigned to each SIP UA, using the IP Profile parameter 'Fax Coders Group'.

■ [0] Transparent = (Default) Device doesn't interfere in the fax transaction and assumes that the SIP UA fully supports fax renegotiation upon fax detection.
■ [1] Only on Answer Side = The SIP UA supports fax renegotiation upon fax detection only if it is the terminating (answering) fax, and doesn't support renegotiation if it is the originating fax.
■ [2] No = The SIP UA doesn't support fax re-negotiation upon fax detection when it is the originating or terminating fax.

Note:

■ This feature is applicable only when both SIP entities do not fully support fax detection (receive or send) and negotiation: one SIP UA must be assigned an IP Profile where the parameter is set to [1] or [2], while the peer SIP UA must be assigned an IP Profile where the parameter is set to [2].
■ This feature is supported only if at least one of the SIP entities use the G.711 coder.
■ This feature requires DSP resources. If there are insufficient resources, the fax transaction fails.

'Fax Rerouting Mode'

sbc-fax-rerouting-mode

[SBCFaxReroutingMode]

Enables the rerouting of incoming SBC calls that are identified as fax calls to a new IP destination.

■ [0] Disable (default)
■ [1] Rerouting without delay

For more information, see Configuring Rerouting of Calls to Fax Destinations.

Note: Configure the parameter for the IP leg that is interfacing with the fax termination.

Media

'Broken Connection Mode'

disconnect-on-broken-connection

[DisconnectOnBrokenConnection]

Defines the handling of calls when RTP or MSRP packets (media) are not received within a timeout.

You can configure the timeout for the following call stages:

■ For RTP:
✔ During call setup: Configure this timeout using the [NoRTPDetectionTimeout] global parameter.
✔ During an established call when packet flow suddenly stops: Configure this timeout using the 'Broken Connection Timeout' global parameter.
■ For MSRP:
✔ During call setup: Configure this timeout using the 'Timeout to Establish MSRP Connection' global parameter.
✔ During an established call when the MSRP socket is closed (no timeout configuration).

Possible values:

■ [0] Ignore = The device maintains the call despite no media and ends the call when signaling ends it (i.e., SIP BYE).
■ [1] Disconnect = (Default) The device ends the call when the timeout expires.
■ [2] Reroute = The device ends the call and then searches the IP-to-IP Routing table (see Configuring SBC IP-to-IP Routing Rules) for a matching rule. If found, the device generates a new INVITE to the new destination. You can also configure a main routing rule whose matching characteristics is explicitly for calls that have broken RTP or MSRP connections. You do this by configuring the 'Call Trigger' parameter in the IP-to-IP Routing table to Broken Connection.
■ [3] Reroute with Original SIP Headers = The device ends the call and then searches the IP-to-IP Routing table (see Configuring SBC IP-to-IP Routing Rules) for a matching rule. If found, the device generates a new INVITE, but with the original SIP headers and non-SDP bodies (XML only of multipart SDP bodies) to the new destination. The SDP body is not copied but re-generated by the device. You can also configure a main routing rule whose matching characteristics is explicitly for calls that have broken RTP or MSRP connections. You do this by configuring the 'Call Trigger' parameter in the IP-to-IP Routing table to Broken Connection.

Note:

■ The device can only detect a broken RTP or MSRP connection if silence compression is disabled for the session.
■ If during a call, the source IP address (from where the packets are received by the device) is changed without notifying the device, the device rejects the packets. To overcome this, configure the parameter to Ignore. With this configuration, the device doesn't detect packets arriving from the original source IP address and switches (after 300 msec) to the packets arriving from the new source IP address.
■ The corresponding global parameter is [DisconnectOnBrokenConnection].

'No RTP Mode'

no-rtp-mode

[NoRTPMode]

Defines the handling of calls when RTP packets (media) are not detected / received within a timeout during early media or upon call connect (i.e., never was RTP). The timeout is configured by the [NoRTPDetectionTimeout] parameter.

■ [1] Disconnect = (Default) The device ends the call.
■ [2] Reroute = The device ends the call and then searches the IP-to-IP Routing table (see Configuring SBC IP-to-IP Routing Rules) for a matching rule. If found, the device generates a new INVITE to the new destination. You can also configure a main routing rule whose matching characteristics is explicitly for calls that have no RTP. To do this, configure the 'Call Trigger' parameter in the IP-to-IP Routing table to Broken Connection.
■ [3] Reroute with Original SIP Headers = The device ends the call and then searches the IP-to-IP Routing table (see Configuring SBC IP-to-IP Routing Rules) for a matching rule. If found, the device generates a new INVITE, but with the original SIP headers and non-SDP bodies (XML only of multipart SDP bodies) to the new destination. The SDP body is not copied, but re-generated by the device. You can also configure a main routing rule whose matching characteristics is explicitly for calls that have broken RTP connections. This is done by configuring the 'Call Trigger' parameter in the IP-to-IP Routing table to Broken Connection.

Note:

■ The device can only detect no RTP if silence compression is disabled for the session.
■ The parameter is not applicable to MSRP sessions.
■ The corresponding global parameter is [NoRTPMode].

'Media IP Version Preference'

media-ip-version-preference

[MediaIPVersionPreference]

Defines the preferred RTP media IP addressing version for outgoing SIP calls (according to RFC 4091 and RFC 4092). The RFCs concern Alternative Network Address Types (ANAT) semantics in the SDP to offer groups of network addresses (IPv4 and IPv6) and the IP address version preference to establish the media stream. The IP address is indicated in the "c=" field (Connection) of the SDP.

■ [0] Only IPv4 = (Default) SDP offer includes only IPv4 media IP addresses.
■ [1] Only IPv6 = SDP offer includes only IPv6 media IP addresses.
■ [2] Prefer IPv4 = SDP offer includes IPv4 and IPv6 media IP addresses, but the first (preferred) media is IPv4.
■ [3] Prefer IPv6 = SDP offer includes IPv4 and IPv6 media IP addresses, but the first (preferred) media is IPv6.

To indicate ANAT support, the device uses the SIP Allow header or to enforce ANAT it uses the Require header:

Require: sdp-anat

In the outgoing SDP, each 'm=' field is associated with an ANAT group. This is done using the 'a=mid:' and 'a=group:ANAT' fields. Each 'm=' field appears under a unique 'a=mid:' number, for example:

a=mid:1
m=audio 63288 RTP/AVP 0 8 18 101
c=IN IP6 3000::290:8fff:fe40:3e21

The 'a=group:ANAT' field shows the 'm=' fields belonging to it, using the number of the 'a=mid:' field. In addition, the ANAT group with the preferred 'm=' fields appears first. For example, the preferred group includes 'm=' fields under 'a=mid:1' and 'a=mid3':

a=group:ANAT 1 3
a=group:ANAT 2 4

If you configure the parameter to a "prefer" option, the outgoing SDP offer contains two medias which are the same except for the "c=" field. The first media is the preferred address type (and this type is also on the session level "c=" field), while the second media has its "c=" field with the other address type. Both medias are grouped by ANAT. For example, if the incoming SDP contains two medias, one secured and the other non-secured, the device sends the outgoing SDP with four medias:

■ Two secured medias grouped in the first ANAT group, one with IPv4 and the other with IPv6. The first is the preferred type.
■ Two non-secured medias grouped in the second ANAT group, one with IPv4 and the other with IPv6. The first is the preferred type.

Note:

■ The parameter is applicable only when the device offers an SDP.
■ The IP addressing version is determined according to the first SDP "m=" field.
■ The feature is applicable to any type of media (e.g., audio and video) that has an IP address.
■ The corresponding global parameter is [MediaIPVersionPreference].

'RTP Redundancy Depth'

rtp-redundancy-depth

[RTPRedundancyDepth]

Enables the device to generate RFC 2198 redundant packets. This can be used for packet loss where the missing information (audio) can be reconstructed at the receiver's end from the redundant data that arrives in subsequent packets. This is required, for example, in wireless networks where a high percentage (up to 50%) of packet loss can be experienced.

■ [0] 0 = (Default) Disable.
■ [1] 1 = Enable - previous voice payload packet is added to current packet.

Note:

■ When enabled, you can configure the payload type, using the [RFC2198PayloadType] parameter.
■ The corresponding global parameter is [RTPRedundancyDepth].

Answer Machine Detection

'AMD Sensitivity Parameter Suite'

amd-sensitivity-parameter-suit

[AMDSensitivityParameterSuit]

Defines the AMD Parameter Suite to use for the Answering Machine Detection (AMD) feature.

■ [0] 0 = (Default) Parameter Suite 0 based on North American English with standard detection sensitivity resolution (8 sensitivity levels, from 0 to 7). This AMD Parameter Suite is provided by the AMD Sensitivity file, which is shipped pre-installed on the device.
■ [1] 1 = Parameter Suite based 1 on North American English with high detection sensitivity resolution (16 sensitivity levels, from 0 to 15). This AMD Parameter Suite is provided by the AMD Sensitivity file, which is shipped pre-installed on the device.
■ [2-7] 2 to 7 = Optional Parameter Suites that you can create based on any language (16 sensitivity levels, from 0 to 15). This requires a customized AMD Sensitivity file that needs to be installed on the device. For more information, contact the sales representative of your purchased device.

Note:

■ To configure the detection sensitivity level, use the 'AMD Sensitivity Level' parameter.
■ For more information on the AMD feature, see Answering Machine Detection (AMD).
■ The corresponding global parameter is [AMDSensitivityParameterSuit].

'AMD Sensitivity Level'

amd-sensitivity-level

[AMDSensitivityLevel]

Defines the AMD detection sensitivity level of the selected AMD Parameter Suite (using the 'AMD Sensitivity Parameter Suite' parameter).

■ For Parameter Suite 0: The valid range is 0 to 7 (default is 0), where 0 is for best detection of an answering machine and 7 for best detection of a live call.
■ For any Parameter Suite other than 0, the valid range is 0 to 15 (default is 8), where 0 is for best detection of an answering machine and 15 for best detection of a live call.

Note: The corresponding global parameter is [AMDSensitivityLevel].

'AMD Max Greeting Time'

amd-max-greeting-time

[AMDMaxGreetingTime]

Defines the maximum duration (in 5-msec units) that the device can take to detect a greeting message.

The valid range value is 0 to 51132767. The default is 300.

Note: The corresponding global parameter is [AMDMaxGreetingTime].

'AMD Max Post Silence Greeting Time'

amd-max-post-silence-greeting-time

[AMDMaxPostSilenceGreetingTime]

Defines the maximum duration (in 5-msec units) of silence from after the greeting time is over, configured by [AMDMaxGreetingTime], until the device's AMD decision.

The valid value is 0 to 32767. The default is 400.

Note: The corresponding global parameter is [AMDMaxPostGreetingSilenceTime].

Local Tones

'Local Ringback Tone Index'

local-ringback-tone-index

[LocalRingbackTone]

Defines the ringback tone that you want to play from the PRT file.

To associate a user-defined tone, configure the parameter with the tone's index number (1-80) as appears in the PRT file. By default (value of -1), the device plays the default ringback tone.

To play user-defined tones, you need to record your tones and then install them on the device using a loadable Prerecorded Tones (PRT) file, which is created using AudioCodes DConvert utility. When you create the PRT file, each recorded tone file must be added to the PRT file with the tone type "acUserDefineTone<Index>". When you want to specify the ringback tone for this parameter, use the index number. For more information, see Prerecorded Tones File.

'Local Held Tone Index'

local-held-tone-index

[LocalHeldTone]

Defines the held tone that you want to play from the PRT file.

To associate a user-defined tone, configure the parameter with the tone's index number (1-80) as appears in the PRT file. By default (value of -1), the device plays the default held tone.

To play user-defined tones, you need to record your tones and then install them on the device using a loadable Prerecorded Tones (PRT) file, which is created using AudioCodes DConvert utility. When you create the PRT file, each recorded tone file must be added to the PRT file with the tone type "acUserDefineTone<Index>". When you want to specify the held tone for this parameter, use the index number. For more information, see Prerecorded Tones File.